feat: using dpf instead of reader in "results" module #1300
Conversation
Codecov ReportAttention: Patch coverage is
❌ Your patch check has failed because the patch coverage (1.42%) is below the target coverage (90.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #1300 +/- ##
==========================================
- Coverage 91.82% 87.30% -4.53%
==========================================
Files 187 189 +2
Lines 15033 15663 +630
==========================================
- Hits 13804 13674 -130
- Misses 1229 1989 +760 🚀 New features to boost your workflow:
|
|
Fundamentally, this all needs to be moved to DPF-Post and DPF post needs to have an even simpler API. Right now we have:
I'd rather not make a 5th. There's a potential new hire that will work for the PyAnsys team on DPF-Post and I'd like him to work on this along with you. |
|
On-hold for the moment until I see how pydpf-post develops. |
|
Closing because I do not have the capacity for this. I think eventually we should use |
|
We are so back... |
germa89
changed the title
|
For the testing of this PR I am testing the three of all... PyMAPDL-Reader (Reader), PyMAPDL-Post (Post) and DPF-Core (DPF). I would have thought that it should be straight forward...
But it seems the Reader shows different results in many cases, mainly related with results not available (or equal to zero): Hence, I am introducing When These are sort of preliminary tests on a not-yet ready DPF-based Result API, but I am happy with the progress so far. |
…t/using-dpf-for-results
for more information, see https://pre-commit.ci
feat: enhance log_test functionality and add test_dpf_backend function before #1300
Co-authored-by: sourcery-ai[bot] <58596630+sourcery-ai[bot]@users.noreply.github.com>
for more information, see https://pre-commit.ci
…/pymapdl into feat/using-dpf-for-results
(Most of the general info has been moved to #4084)
Migrate most of the backend and set the foundations for following PRs. Aiming to migrate most of the numerical methods. Plotting will be in a follow up PR.
Launch DPF when running in containerThis should not be part of PyMAPDL since if it is local, it will be automatically detected, and if it is remote, we should not own that resource. It could be something for PyMAPDL developers.To migrate
Missing
To be done in follow up PRs
materialsThe material API is lacking many features. So far, we cannot read temperature-dependent materials, and it seems neither some electric properties like permitivity.
See:
mesh: Requires replicate a full class. It will be a different issue.cylindrical_nodal_stress.element_solution_dataThis requires a mapping sort of:
nodal_boundary_conditionsnodal_input_forceparse_coordinate_systemresult_dof: Return a list of degrees of freedom for a given result number.section_dataDone
available_resultselement_componentselement_lookupelement_stressfilenamen_resultsn_sectornodal_accelerationnodal_displacementnodal_elastic_strainnodal_plastic_strainnodal_reaction_forcesnodal_solutionnodal_static_forcesnodal_stressnodal_temperaturenodal_thermal_strainnodal_time_historynodal_velocitynode_componentsparse_step_substeppathlib_filenameprincipal_nodal_stresstime_valuesversionTo not migrate.
A
NotImplementedErrorwill be raised.text_result_tableUsed for the text in the plots. Not porting it.write_tables: Write binary tables to ASCII.read_record: Read a record from the opened file. Records are hidden in DPF.overwrite_element_solution_record: DPF cannot write solution files.overwrite_element_solution_records: DPF cannot write solution files.cs_4x4- I couldn't make it work locally, so I'm not porting it. It will raise a not implemented error.solution_infoIt doesn't make sense to be ported at the moment.
There are many methods which are duplicate frommapdl.post_processing, I will probably redirect one to another (I don't know which one should prevail, probably post-processing).DPFResultclass should provide a way to manipulate RST files without having an MAPDL instance alive.Full list of Reader class methods
The complete lists of functions in that class are:
Show full list of Result class functions
Notes
Launch DPF when running in containerThis should not be part of PyMAPDL since if it is local, it will be automatically detected, and if it is remote, we should not own that resource. It could be something for PyMAPDL developers.Summary by Sourcery
Replace the legacy reader‐based results interface with a new DPF backend: introduce a global switch to toggle backends, implement and expose the
DPFResultclass with migrated public APIs using ansys-dpf-core, update test infrastructure and CI workflows to support DPF testing, and refine misc, launcher, and pytest utilities to accommodate the change.New Features:
use_reader_backendswitch in MAPDL.DPFResultclass underansys.mapdl.core.reader.resultmigrating public result APIs to use ansys-dpf-core.get_ipandparse_ip_routefor IP detection and switch GRPC/Docker connection logic.Bug Fixes:
MapdlGrpc.sysand clarify assertion error when reusing MAPDL instances.Enhancements:
PYMAPDL_ADDITIONAL_SWITCHESin headers.mapdl.resultfile‐path handling to create isolated temp directories and enrich FileNotFoundError messages._parse_ip_routeusage in launcher and misc modules.CI:
TEST_DPF_BACKENDenvironment variable in CI workflows to enable/disable DPF tests.Documentation:
Tests:
tests/test_result.pyand update fixtures fortest_dpf_backend.tests/conftest.py,tests/common.py, and test launcher to integrate DPF backend testing.Summary by Sourcery
Migrate the "results" module to use ansys-dpf-core by introducing a new DPFResult class and a global use_reader_backend switch, update MAPDL core to support both backends, refine error handling and temporary file management, and extend CI workflows and tests to validate the new DPF-based implementation.
New Features:
Enhancements:
CI:
Documentation:
Tests: